Fix persistence and add support of custom themes of theme changer #44
Conversation
src/aio/aio_theme_changer.py
Outdated
| self, radio_props={}, button_props={}, offcanvas_props={}, aio_id=None, | ||
| self, | ||
| aio_id: str = str(uuid.uuid4()), | ||
| custom_themes: dict[str, str] = None, |
There was a problem hiding this comment.
This requires at least python 3.9. We should still support 3.8 until Dash drops that support. Probably need to update the ThemeSwitch component too.
There was a problem hiding this comment.
Last commit adds backward compatibility with python 3.8.0
src/aio/aio_theme_changer.py
Outdated
| # style the labels | ||
| radio_props['options'] = [ | ||
| { | ||
| "label": html.Div( |
There was a problem hiding this comment.
This is a much better way to do it, but dbc.RadioItems only supported components as props for labels in dbc v1.4.0 released Feb 23. It will break for anyone using an older version of dbc
There was a problem hiding this comment.
Last commit adds backward compatibility with dbc 1.3.1
Rollback using #theme-switch-label/#theme-switch-label-dark CSS styles
But still no need to apply label_id when user provide a custom radio_props['options'], like
ThemeChangerAIO(
aio_id="theme",
radio_props={
"options": [
{"label": "Cyborg", "value": dbc.themes.CYBORG},
{"label": "Vapor", "value": dbc.themes.VAPOR}
],
"value": dbc.themes.CYBORG,
"persistence": True,
}
)Its handled internally using the list dark_themes = (dbc_dark_themes + custom_dark_themes)
But if someone still applies label_id it won't be overridden, for instance it's possible to set "label_id": "" to remove the styling.
src/aio/aio_theme_changer.py
Outdated
|
|
||
| The ThemeChangerAIO component updates the stylesheet when the `value` of radio changes. (ie the user selects a new theme) | ||
|
|
||
| - param: `radio_props` A dictionary of properties passed into the dbc.RadioItems component. The default `value` is `dbc.themes.BOOTSTRAP` | ||
| - param: `radio_props` A dictionary of properties passed into the dbc.RadioItems component. The default `value` is `BOOTSTRAP` |
There was a problem hiding this comment.
This will be a breaking change too - The value is now the link rather than the name of the of the theme. But is this required in order to support custom stylesheets?
There was a problem hiding this comment.
Yes it was a breaking change, actually it was the opposite, it used the url instead of the name.
I preferred to use the name, but rollback in the previous commit to not have a breaking change... but forget to also rollback this description 🙏
Corrected in the last commit.
Remove `clientsideCallbacks.js`, JS functions directly in Python code
|
New commit changelog:
|
|
@sdidier-dev this does seem to properly apply persistent themes, but on the first theme load there's a split second flashbang (everything's white) while a theme is loading. So if you load the page, and then switch from |
|
Hi @mayushii21! can you try with this last commit if that's better? |
|
@sdidier-dev while your solution did help, it still flashed on initial load, and relying on delays isn't best practice. I don't quite understand the logic flow of everything you were doing there, so I forked your fork and fiddled around. I created a pull request to your fork with a solution that seems to work well for me, relying on onload of the new stylesheet instead of delaying to set the href attribute. Please take a look. Not having to wait an entire half second also makes it feel a lot snappier - better user experience |
rework theme application to avoid delay and flash
|
Thanks @mayushii21 for the improvement! |
Hi there! 😁
Here is a PR modifying the
ThemeChangerAIOcomponent inspired by the update of theThemeSwitchAIO.Change log:
assets_folderandassets_url_path)